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(54) Processing of graphical digital picture data in a decoder 

(57) A decoder 1 3 for a digital audiovisual transmis- 
sion system, the decoder 13 comprising a general proc- 
essor means 20 for decompressing compressed digital 
picture data and a graphic processor means 36 for pre- 
paring the decompressed data for display, character- 
ised in that the general processor means 20 is adapted 
to decompress and store an image file in its substan- 
tially original format and subsequently to convert the 
image file to at least a second format for storage and 
display, the first and second format versions of the 
image file being stored contemporaneously in a mem- 
ory 20 of the decoder. 
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Description 

[0001] The present invention relates to a decoder for 
a digital audiovisual transmission system, the decoder 
comprising a processor means for decompressing and 
displaying compressed digital picture data and memory 
means. 

[0002] Broadcast transmission of digital data is well- 
known in the field of pay TV systems, where scrambled 
audiovisual information is sent, usually by a satellite or 
satellite/cable link, to a number of subscribers, each 
subscriber possessing a decoder capable of descram- 
bling the transmitted program for subsequent viewing. 
Terrestrial digital broadcast systems are also known. 
Recent systems have used the broadcast link to trans- 
mit other data, in addition to or as well as audiovisual 
data, such as computer programs or interactive applica- 
tions. 

[0003] In the most basic level of functionality of such 
systems, digital audio and video data relating to the tel- 
evised program is transmitted in a compressed format, 
for example, in accordance with the MPEG-2 compres- 
sion standard. The decoder receives and decom- 
presses this data in order to regenerate the televised 
program. 

[0004] In addition to simple televised program data, it 
is becoming increasingly common for the decoder to be 
required to handle other compressed image or graphic 
data. For example, in the case where the decoder 
includes web browser capabilities, the processor of the 
decoder may be required to receive and decompress 
downloaded digital picture data, for example, still video 
pictures, graphic icons, moving computer generated 
images etc. This picture information may be displayed 
over the normal televised program images. 
[0005] Such still or moving picture data may be typi- 
cally received in one of any number of compressed for- 
mats that are currently used in the context of PC based 
web browsers. For example, a picture may be formatted 
and compressed according to the well-known GIF or 
PNG standards, where an image is described by a col- 
our look-up table defining a table of colours and a matrix 
of pixel values referring to this table, the matrix data 
being compressed according to a known compression 
procedure to prepare the GIF/PNG picture. Alterna- 
tively, the picture may be formatted and compressed as 
a still MPEG or JPEG image, in which each pixel is 
directly associated with a red/green/blue colour value. 
[0006] The graphic processor used by a decoder to 
prepare the images for display is normally adapted to 
process such images once they have been decom- 
pressed and converted by the general processor into 
image files in one or more predetermined pixmap for- 
mats. For example, the graphic processor may be 
adapted to display image files submitted in the CLUT4 
or CLUT8 formats, in which the principle of a look-up 
table is adhered to, or in the RGB format, in which each 
pixel has a RGB value. 



[0007] These pixmap image file formats reflect the 
pixel composition of the original image and are distinct 
from, although closely related to, the compression for- 
mats referred to above. GIF/PNG pictures decompress 
5 to form a pixmap image file with a look-up table and 
JPEG/MPEG image files decompress to pixmap files 
without such a table. 

[0008] In a PC environment, the processor power and 
memory space available means that a number of picture 

10 files compressed according to different formats may be 
received, decompressed and displayed concurrently, 
the graphic processor within a PC being adapted to eas- 
ily handle multiple formats. In contrast, in a decoder 
environment, the memory and processor power availa- 

15 ble are considerably more limited, the graphic processor 
also having to handle at least the MPEG data associ- 
ated with the televised transmission. In such a case, it 
may not be possible to convert and display image files in 
a plurality of formats. 

20 [0009] For example, in the case of an original image 
formatted in an RGB format and compressed with the 
JPEG algorithm, the main processor of the decoder 
may simply decompress and store this image file (and, 
indeed, all subsequently received image files) in a fixed 

25 CLUT format. In this way, the graphic processor will only 
have to handle one type of image file. Whilst this 
method enables the decoder to effectively handle multi- 
ple format data, there may be an unnecessary loss of 
image quality. For example, if no other image file is 

30 being handled by the graphic processor, it may not be 
necessary to impose a fixed converted image file for- 
mat. 

[001 0] It is an object of the present invention to over- 
come these disadvantages of the prior art. 

35 [001 1 ] According to the present invention there is pro- 
vided a decoder for a digital audiovisual transmission 
system, the decoder comprising a processor means for 
decompressing and displaying compressed digital pic- 
ture data and memory means, characterised in that the 

40 processor means is adapted to decompress and store 
an image file in its substantially original format and sub- 
sequently to convert the image file to at least a second 
format for storage and display, the first and second for- 
mat versions of the image file being stored contempora- 

45 neously in the memory means. 

[001 2] The decompression and storage of the original 
format version of the compressed image enables the 
decoder thereafter to generate alternate format image 
files to be sent to the processor for display according to 

so the current capacity and operation of the graphics proc- 
essor. 

[0013] For example, in the event that the original 
image is in a n true colour" or RGB format and the load 
and operation of the graphics processor permits display 
55 in this format, the image may be decompressed and dis- 
played substantially "as is w , that is, an image file without 
look-up table. Nevertheless, a decimation of the number 
of bits associated with each pixel may be carried out to 
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change the resolution whilst substantially maintaining 
same format. Equally, in the case of a picture com- 
pressed with a look-up table (GIF/PNG), the same look- 
up table will be stored and referred to in the display of 
the image. 

[0014] If a display cannot be effected using the origi- 
nal format, the processor may convert the image file to 
a different format for display, the original file being nev- 
ertheless kept for future use. In this way, the present 
invention enables the highest quality display to be 
effected at any time within the memory and processing 
constraints of the decoder at that moment. 
[0015] In one embodiment, the processor means is 
adapted to convert the image file into a plurality of for- 
mats stored contemporaneously with the original ver- 
sion in a memory of the decoder. 
[0016] Preferably, the processor means is adapted to 
read and display multiple format versions of an image 
file stored at that time. For example, the processor may 
be adapted to display the same image twice in two dif- 
ferent screen windows and according to the two differ- 
ent formats used in the windows. 
[001 7] In particular, the processor may be adapted to 
define a plurality of regions in a graphic layer corre- 
sponding to a region of the display, each region being 
defined in part by a location coordinate and by the for- 
mat version of the image files that may be processed by 
the processor means and displayed in this region. 
[0018] This division of the screen area into format 
areas is particularly characteristic of the decoder envi- 
ronment. For example, one region within the graphic 
layer may correspond to a region where image files in a 
particular CLUT format may be displayed, whilst 
another region may be associated with image files in an 
RGB format. 

[0019] In such a realisation, the processor means is 
preferably adapted to convert an original image file des- 
tined to be displayed in a region into a version corre- 
sponding to the format version currently used in that 
region. For example, where an RGB original format 
image is to be displayed in the same region where a 
CLUT format image is already being displayed, the 
processor means will convert the image into the appro- 
priate CLUT format for display. 

[0020] In one embodiment, the processor means is 
adapted to process images in the graphic layer superim- 
posed over real-time audiovisual digital data and corre- 
sponding to one or more layers displayed on the screen 
beneath the graphic layer. Images in the graphic layer 
may equally be displayed by the processor superim- 
posed over other types of image file data displayed in 
layers beneath the graphic layer. 
[0021] In one embodiment, the processor means is 
adapted to decompress picture data sent in a compres- 
sion standard that uses a look-up table, for example, the 
GIF or PNG standard. In addition or alternatively, the 
processor means is adapted to decompress picture 
data sent in a standard that uses a red/green/blue col- 



our value associated with each pixel, for example, 
MPEG or JPEG. 

[0022] As discussed above, the advantage of the two- 
step decompression and conversion process used in 

5 the present invention lies in the ability to process the 
original format image file in any number of ways. In 
some circumstances, however, it may be desirable to 
use a fixed format for all image data. 
[0023] Therefore, in one preferred embodiment of the 

10 invention, the processor means is further adapted to 
directly decompress picture data regardless its com- 
pression format into a image file of a predetermined for- 
mat. 

[0024] In particular, the processor means may be fur- 

15 ther adapted to directly decompress picture data into a 
format which uses a colour look-up table, for example, 
the CLUT4 or CLUT8 format. In addition, or alterna- 
tively, the processor means may be further adapted to 
directly decompress picture data into a format which 

20 uses a red/green/blue colour value associated with 
each pixel, for example the RGB1 6 format. 
[0025] All functions of decompression and display of 
data may be integrated in a single processor means. 
Alternatively, the processor means may comprise at 

25 least a general processor and a graphic processor for 
handling decompression and display, respectively. 
[0026] The present invention has been discussed in 
relation to a decoder apparatus. The present- invention 
equally extends to a method of digital image processing 

30 within such a decoder, corresponding to the general and 
preferred aspects of the invention discussed above. 
[0027] In the context of the present application the 
term < (digital audiovisual transmission system ) ) refers 
to all transmission systems for transmitting or broad- 

35 casting primarily audiovisual or multimedia digital data. 
Whilst the present invention is particularly applicable to 
a broadcast digital television system, the present inven- 
tion may equally be used in filtering data sent by a fixed 
telecommunications network for multimedia internet 

40 applications etc. 

[0028] Similarly, the term "decoder" is used to apply to 
an integrated receiver/decoder for receiving and 
decrypting an encrypted transmission, the receiver and 
decoder elements of such a system as considered sep- 

45 arately, as well as to a receiver capable of receiving 
non-encrypted broadcasts. The term equally covers 
decoders including additional functions, such as web 
browsers, together with decoders integrated with other 
devices, for example, integrated VHS/decoder devices, 

so digital televisions or the like. 

[0029] The term MPEG refers to the data transmission 
standards developed by the International Standards 
Organisation working group "Motion Pictures Expert 
Group" and notably the MPEG-2 standard developed for 

55 digital television applications and set out in the docu- 
ments ISO 13818-1, ISO 13818-2, ISO 13818-3, and 
ISO 13818-4. In the context of the present patent appli- 
cation, the term includes all variants, modifications or 
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developments of the basic MPEG formats applicable to 
the field of digital data transmission. 
[0030] There will now be described, by way of exam- 
ple only, a preferred embodiment of the present inven- 
tion, with reference to the attached figures, in which: 

Figure 1 shows an overview of a digital television 
system; 

Figure 2 shows the elements of the 
receiver/decoder of Figure 1 ; 

Figure 3 shows in layer form the image data proc- 
essed by the graphic processor of Figure 2; 

Figure 4 shows in detail the graphic layer of Figure 
3; and 

Figure 5 shows the decompression and conversion 
steps carried out in a number of cases on com- 
pressed image data. 

[0031] An overview of a digital television system 1 
according to the present invention is shown in Figure 1 
The invention includes a mostly conventional digital tel- 
evision system 2 that uses the known MPEG-2 com- 
pression system to transmit compressed digital signals. 
In more detail. MPEG-2 compressor 3 in a broadcast 
centre receives a digital signal stream (typically a 
stream of video signals). The compressor 3 is con- 
nected to a multiplexer and scrambler 4 by linkage 5. 
[0032] The multiplexer 4 receives a plurality of further 
input signals, assembles the transport stream and 
transmits compressed digital signals to a transmitter 6 
of the broadcast centre via linkage 7, which can of 
course take a wide variety of forms including telecom- 
munications links. The transmitter 6 transmits electro- 
magnetic signals via uplink 8 towards a satellite 
transponder 9, where they are electronically processed 
and broadcast via notional downlink 10 to earth receiver 
12, conventionally in the form of a dish owned or rented 
by the end user. The signals received by receiver 12 are 
transmitted to an integrated receiver/decoder 13 owned 
or rented by the end user and connected to the end 
user's television set 14. The receiver/decoder 13 
decodes the compressed MPEG-2 signal into a televi- 
sion signal for the television set 14. 
[0033] Other transport channels for transmission of 
the data are of course possible, such as terrestrial 
broadcast, cable transmission, combined satellite/cable 
links, telephone networks etc. 

[0034] In a multichannel system, the multiplexer 4 
handles audio and video information received from a 
number of parallel sources and interacts with the trans- 
mitter 6 to broadcast the information along a corre- 
sponding number of channels. In addition to audiovisual 
information, messages or applications or any other sort 
of digital data may be introduced in some or all of these 



channels interlaced with the transmitted digital audio 
and video information. 

[0035] A conditional access system 1 5 is connected to 
the multiplexer 4 and the receiver/decoder 13, and is 
5 located partly in the broadcast centre and partly in the 
decoder. It enables the end user to access digital televi- 
sion broadcasts from one or more broadcast suppliers. 
A smartcard, capable of deciphering messages relating 
to commercial offers (that is, one or several television 
10 programmes sold by the broadcast supplier), can be 
inserted into the receiver/decoder 13. Using the 
decoder 13 and smartcard, the end user may purchase 
commercial offers in either a subscription mode or a 
pay-per-view mode. 
is [0036] As mentioned above, programmes transmitted 
by the system are scrambled at the multiplexer 4, the 
conditions and encryption keys applied to a given trans- 
mission being determined by the access control system 
15. Transmission of scrambled data in this way is well 
20 known in the field of pay TV systems. Typically, scram- 
bled data is transmitted together with a control word for 
descrambling of the data, the control word itself being 
encrypted by a so-called exploitation key and transmit- 
ted in encrypted form. 
25 [0037] The scrambled data and encrypted control 
word are then received by the decoder 13 having 
access to an equivalent of the exploitation key stored on 
a smart card inserted in the decoder to decrypt the 
encrypted control word and thereafter descramble the 
30 transmitted data. A paid-up subscriber will receive, for 
example, in a broadcast monthly ECM (Entitlement 
Control Message) the exploitation key necessary to 
decrypt the encrypted control word so as to permit view- 
ing of the transmission. 
35 [0038] An interactive system 1 6, also connected to the 
multiplexer 4 and the receiver/decoder 13 and again 
located partly in the broadcast centre and partly in the 
decoder, enables the end user to interact with various 
applications via a modem back channel 1 7. The modem 
40 back channel may also be used for communications 
used in the conditional access system 15. An interactive 
system may be used, for example, to enable the viewer 
to communicate immediately with the transmission cen- 
tre to demand authorisation to watch a particular event, 
45 download an application etc. 

[0039] Referring to Figure 2, the elements of the 
receiver/decoder 13 or set-top box adapted to be used 
in the present invention will now be descrtoed. The ele- 
ments shown in this figure will be described in terms of 
so functional blocks. 

[0040] The decoder 1 3 comprises a central processor 
20 including associated memory elements and adapted 
to receive input data from a serial interface 21 , a parallel 
interface 22. a modem 23 (connected to the modem 
55 back channel 1 7 of Fig 1 ). and switch contacts 24 on the 
front panel of the decoder. 

[0041 ] The decoder is additionally adapted to receive 
inputs from an infra-red remote control 25 via a control 
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unit 26 and also possesses two smartcard readers 27, 
28 adapted to read bank or subscription smartcards 29, 
30 respectively. The subscription smartcard reader 28 
engages with an inserted subscription card 30 and with 
a conditional access unit 29 to supply the necessary 
control word to a demultiplexer/descrambler 30 to ena- 
ble the encrypted broadcast signal to be descrambled. 
The decoder also includes a conventional tuner 31 and 
demodulator 32 to receive and demodulate the satellite 
transmission before being filtered and demultiplexed by 
the unit 30. 

[0042] Processing of data within the decoder is gener- 
ally handled by the central processor 20. The software 
architecture of the central processor may correspond to 
that used in a known decoder and will not be described 
here in any detail. It may be based, for example, on a 
virtual machine interacting via an interface layer with a 
lower level operating system implemented in the hard- 
ware components of the decoder. In terms of the hard- 
ware architecture, the decoder will be equipped with a 
processor, memory elements such as ROM, RAM, 
FLASH etc. as in known decoders. 
[0043] In the case of received audio and video signals, 
and as will be described in more detail below, the MPEG 
packets containing these signals will be demultiplexed 
and filtered so as to pass real time audio and video data 
in the form of a packetised elementary stream (PES) of 
audio and video data to dedicated audio and video proc- 
essors or decoders 33, 34. The converted output from 
the audio processor 33 passes to a preamplifier 35 and 
thereafter via the audio output of the receiver/decoder. 
The converted output from the video processor 34 
passes via a graphic processor 36 and PAL/SECAM 
encoder 37 to the video output of the receiver/decoder. 
The video processor may be of a conventional type, 
such as the ST 3520A of SGS Thomson. 
[0044] The graphic processor 36 additionally receives 
graphic data for display (such as generated images etc) 
from the central processor 20 and combines this infor- 
mation with information received from the video proces- 
sor 34 to generate a screen display combining moving 
images together with overlaid text or other images. An 
example of a graphic processor adapted to carry out 
this sort of operation is the CM 9310 of C-CUBE. 
[0045] In the case of received teletext and/or subtitle 
data, the conversion of the real time PES data to gener- 
ate the appropriate images may also be handled by 
dedicated processors. However, in most conventional 
systems, this is handled by the general processor 20. 
[0046] In point of fact, many of functions associated 
with the elements such as the graphic processor 36, 
video decoder 34, central processor 20 etc. may be 
combined or divided out in a number of ways, e.g. to 
integrate the central and graphic processors in a single 
processor means etc. 

[0047] Referring now to Figure 3, the functionality of 
the graphic processor 36 will now be described. As dis- 
cussed above, the graphic processor receives and proc- 



esses real time video data from the video decoder 34 
together with graphic data received from the general 
processor 20 in order to generate an overlaid screen 
display. 

5 [0048] As shown in Figure 3, the graphic processor 36 
is adapted to process input data divided into four distinct 
layers; a background layer 40, an MPEG layer 41, a 
graphic layer 42 and a cursor layer 43. As will be under- 
stood, the background layer 40 corresponds to the low- 

10 est layer of the screen display, the other layers being 
progressively superimposed with varying degrees of 
translucency or opacity over this layer. 
[0049] In the case where the decoder is configured to 
display a broadcast video signal, the background and 

is MPEG layers 40, 41 correspond to the stream of data 
received from the video decoder 34, the layer 40 corre- 
sponding to MPEG still pictures received from the 
decoder 34 and the layer 41 corresponding to a moving 
video MPEG signal received from the decoder. The divi- 
de sion of a video signal into a fixed and a changing part is 
a known characteristic of MPEG compression. 
[0050] Other configurations of the decoder are possi- 
ble, for example, where the background and MPEG lay- 
ers 40, 41 are completed by picture data in any number 

25 of formats received from the processor 20. For example, 
in the case where the decoder is acting in web browser 
configuration, the processor 20 may supply still and/or 
moving picture data to complete the layers 40, 41 . The 
layer 40 may equally correspond, for example, to a 

30 background colour and the layer 41 to one or more win- 
dows displayed over the background and containing, for 
example, information, moving icons or the like. 
[0051] Still and moving image data from the back- 
ground and MPEG layers 40, 41 are mixed together by 

35 the graphic processor 36. as represented by the ele- 
ment 44, and a combined output provided. Mixing of the 
MPEG layer information 41 over the background layer 
40 by the graphic processor may carried out using a so- 
called alpha blending factor to permit a greater or lesser 

40 degree of translucency of the pixels in the MPEG layer 
image. In the case of a moving video image received 
from the video decoder 34, the same blending factor is 
used for all pixels within the video sequence. In the case 
of picture data from the central processor 20, the value 

45 of the blending factor for the layer 41 may be different for 
different parts of the screen. 

[0052] The graphic layer 42 is used for texts, shapes, 
icons etc that will be displayed on the screen over the 
images taken from the layers 40, 41, for example, to 

so permit display of a moving icon or the like generated by 
the processor 20 over a real-time video sequence taken 
from the video decoder 34. As this embodiment of the 
present invention relates primarily to treatment of data 
in this layer, the characteristics of data in this layer will 

55 be described in more detail below in relation to Figure 4. 
[0053] In a similar manner to the blending carried out 
for the layers 40, 41 , the element 45 carries out a blend- 
ing of the graphic layer 42 with the combined output of 
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the layers 40, 41 . As will be described, different regions 
within the graphic layer 42 may be assigned a different 
blending factor and a corresponding different level of 
translucency depending on the characteristics of the 
data within each region. 

[0054] A f inal layer, the cursor layer, is shown at 43 
and represents an opaque cursor image, generated by 
hardware under control of the central processor 20 and 
superimposed over all the previous layers. As shown at 
46, this layer is combined with the summed output from 
the combination of all previous layers to generate a final 
combined output 47 sent to the encoder 37 for subse- 
quent display. Onlike the previous layers, the cursor 
presents a continuously opaque appearance and is 
superimposed over the combined layers without any 
blending. 

[0055] Turning now to Figure 4, the graphic layer is 
divided in operation into one or more rectangular 
regions 50, each region being defined by its width, its 
height, its display co-ordinate 51 and the colour system 
used within that region. Any pixel in the layer not 
belonging to a designated region, as shown at 52, is 
kept transparent. The display coordinate 51 is defined 
as the co-ordinate of the upper left hand comer of the 
region, as shown. The pixel size of all the regions is 
never more than the full screen resolution, that is, 720 X 
576 for PAL, 720 X 480 for NTSC. 
[0056] Concerning the colour system to be used in a 
region, the information provided to the graphic proces- 
sor 36 to construct the layer is coded in pixmap form, 
each pixel being identified by a co-ordinate and a colour 
reference. In practice, a number of pixmap formats may 
be handled by the graphic processor, such as: 

CLUT4: 4 bits/pixel addressing a colour look-up 
table (CLUT) with 16 entries 

CLUT8: 8 bits/pixel addressing a colour look-up 
table (CLUT) with 256 entries 

RGB 16: 16 bits/pixel specifying the red/greerVblue 
mix for each pixel 

[0057] In the case of the RGB 16 format, a colour to be 
displayed is simply defined with reference to the pre- 
ponderance of each of the primary colours 
red/green/blue used by the system to generate a colour. 
[0058] In the case of a CLUT type format, each pixel 
includes a reference to a designated colour value in a 
look-up table. This colour in turn is defined by a 24 bit 
red/green/blue value eventually used by the system to 
generate a colour. A 6 bit alpha blending factor may also 
be associated with each colour value (see below). 
[0059] As indicated above, the size of the look-up 
table and the number of colours available can vary, e.g. 
to define an image with reference to 16 or 256 colours. 
Equally, the colours defined within a look-up table can 
vary between tables, e.g. one table defining more col- 



ours in a certain part of the spectrum than in another 
part. Before display of a region, the look-up table is 
loaded into the graphic processor. 
[0060] The graphics processor 36 may resize in real 
5 time each region and move horizontally and vertically a 
region on the screen, on the condition that there is no 
overlapping between regions. Additionally, as men- 
tioned above, each region may be blended independ- 
ently with the layers below using a particular alpha 
10 blending factor. In the case of each of the formats, the 
following possibilities exist: 

CLUT4: A global 6 bit alpha blending factor applied 
throughout the region OR each colour entry in the 
is table has a 6 bit alpha blending factor. One colour 
value may be transparent. 
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CLUT8: A global 6 bit alpha blending factor applied 
throughout the region OR each colour entry in the 
table has a 6 bit alpha blending factor. One colour 
value may be transparent. 

RGB16: A global 6 bit alpha blending factor applied 
throughout the region. 



[0061 ] The pixmap formats discussed above are dis- 
tinct from the compressed multimedia formats conven- 
tionally used to transmit the images eventually to be 
displayed in the graphic layer. For example, a picture to 
30 be displayed in one of the graphic regions may be com- 
pressed as an MPEG still picture, a JPEG format pic- 
ture, a GIF format picture or a PNG format picture. In 
the following description the term "picture" will always 
be used to refer to image data in a compressed format. 
35 [0062] The MPEG format has been described in the 
introduction in relation to the ISO developed standards. 
The JPEG and GIF standards are equally well-known 
multimedia formats, often found in images sent via the 
internet, whilst the PNG format is, at the time of writing, 
40 a more recent standard introduced as a competitor to 
the proprietary GIF standard. As will be discussed 
below, images received in the MPEG, JPEG, GIF or 
PNG formats are decompressed by a routine within the 
processor 20 into one of the CLUT or RGB pixmap for- 
45 mats discussed above. 

[0063] It will of course be understood that, whilst the 
description refers in this instance to specific display (or 
pixmap) formats and transmission (or compressed) for- 
mats, the present invention is in no way limited to the 
so use of these particular formats. 

[0064] In the case of GIF and PNG type formats, these 
compressed formats are based on original image files 
that include a look-up table. Direct decompression of a 
GIF or PNG compressed picture will result in an image 
55 in a CLUT pixmap format. However, as will be dis- 
cussed, a GIF or PNG picture may also be decom- 
pressed directly into the RGB pixmap format, for 
example. Similarly, whilst an MPEG/JPEG picture is 
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compressed in an RGB mode, such that it may be 
directly decompressed into a 16 bit RGB pixmap, there 
may be some circumstances in which it may be desired 
to transform the picture into a CLUT format. 
[0065] Figure 5 represents schematically possible 
decompression and conversion steps that may be car- 
ried out by the general processor 20 on a received com- 
pressed GIF or PNG type picture according to this 
embodiment of the invention. Three types of decom- 
pression activated in response to three decom- 
pression commands, DECOMP_ORIGINAL, 
DECOMP_TO_CLUT and DECOM P__TO_RGB are 
shown. The decompression steps are illustrated in rela- 
tion to a CLUT formatted picture, but similar decom- 
pression steps may also be effected in respect of JPEG 
and MPEG still pictures in response to the same com- 
mands. 

[0066] DECOM P_ORIGINAL. A received GIF/PNG 
picture 60 is shown, comprising a look-up table CLUT 
indicated at 61 and pixel ID data f(ID) defining colour 
values for each pixel in the image, as indicated at 62. In 
the uppermost decompression step 63, the picture in 
the transmitted file is decompressed and stored in 
memory in its substantially original format as shown at 
65, i.e. in a CLUT mode with a set ol pixel data 66 refer- 
ring to its associated CLUT table 67. 
[0067] The number of entries in the CLUT table (1 6 or 
256) and the subsequent degree of colour resolution 
depends on the original format of the table. Similarly, the 
exact RGB bit value associated with each colour is 
defined by the CLUT table in question, which is pre- 
served in an unchanged form. 

[0068] In the present system, the resulting decom- 
pressed image is stored in memory. In a subsequent 
conversion step shown at 64, the image may be further 
converted into a second pixmap format 68, such as an 
alternative CLUT format, also stored in the system 
memory. 

[0069] For example, an image comprising a 256 entry 
CLUT table may be converted into an image with a 16 
entry CLUT table. Alternatively, one characteristic CLUT 
table may be transformed into a different CLUT table, 
with different RGB values associated with some or all of 
the entries. At the same time as the transformation of 
the CLUT table, the pixel ID values will be transformed. 
The necessary algorithms to carry out these transfor- 
mations will be known to one skilled in the art. 
[0070] The advantage of this double decompres- 
sion/conversion as compared to the other decompres- 
sion steps described below will be understood in 
relation to the zoning of the graphic layer shown in Fig- 
ure 4. In a PC environment, the size of the memory and 
processing capability of the PC means that many image 
windows, each having a particular CLUT table, may be 
opened. In this case, an image may always be directly 
decompressed and displayed in its original format. 
[0071] In contrast, in a decoder environment, memory 
and processor constraints lead to the arrangement of 



regions described above, in which each region 50 is 
associated with a particular pixmat format. In one exam- 
ple, one region may be associated with a CLUT4 format, 
with a predetermined 16 entry look-up table held by one 

5 or more images already displayed in this region, whilst 
another region may be associated with CLUT8 format 
with another predetermined look-up table of 256 entries. 
[0072] In the case of a new picture file defining, for 
example, an icon to be displayed in both of these 

io regions, the picture file will first be decompressed 
according to the DECOMP_ORIGINAL command to 
provide a file with the original CLUT table associated 
with this image. This original file, stored in memory, may 
then be reduced and converted to the CLUT4 format 

15 used by the first region, as well as to the CLUT8 format 
(with associated specific CLUT table value) used by the 
second region. Further reconversions may effected at 
will on the original file. 

[0073] In contrast, if the original picture file has never 

20 been decompressed, but has been immediately con- 
verted to a standard pixmap value used in one region 
(see below), it may not be possible to effectively recon- 
vert the image in this format to a second format associ- 
ated with another region. For example, where a CLUT8 

25 picture is simultaneously decompressed and converted 
into a standard CLUT4 format, there will be a loss of 
information associated with the image, rendering any -i 
reconversion to a CLUT8 format unreliable. 
[0074] Nevertheless, in some circumstances it may be 

30 desirable to fix the end format of all pixmap files in 

advance of conversion. In this case, the following com- ^ 

mands may be given to general processor. 

[0075] DECOMP_TO_CLUT. With this command, the 

picture, whatever the format of the original file (CLUT4, 

35 CLUT8, RGB) is decompressed at 69 and converted in :Z 
a CLUT format pixmap shown at 70. The resolution of ■«$ 
the CLUT. as well as the RGB values of each of its . ^§ 

entries is imposed at the moment of decompression. 
[0076] D E COM P_TO_RG B. With this command, the 

40 picture, whatever the format of the original file (CLUT4, 
CLUT8, RGB) is decompressed at 71 and converted in 
a RGB format pixmap shown at 72. The resolution of the 
RGB format is fixed at the moment of decompression. 
[0077] In the case of a picture originally in true colour 

45 or MPEG/JPEG format. the command 
DECOMPJDRIGINAL will return a decompressed 
image in RGB. Although the format of the decom- 
pressed file corresponds to the original (i.e. no look-up 
table), a slight change of resolution may require a con- 

50 version from true colour to RGB 16 to be provided 
at the moment of encryption. The command 
DECOMP_TO_CLUT acting on an MPEG/JPEG file will 
decompress and convert the picture into an image in 
CLUT format, the resolution of the CLUT as well as the 

55 values of each of its entries being imposed at the 
moment of decompression. The command 
DECOMP_TO_RGB will have the same effect on the 
picture in this case as the command 
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DECOMPJDRIGINAL, that is, to decompress and con- 
vert the picture from true colour to RGB1 6 format. 
[0078] As will be understood, the decompression/con- 
version algorithms necessary to carry out the above 
operations are known. However, the application of such 
algorithms to create each of the stored files indicated 
above is not known in the context of decoder technol- 
ogy. In particular, the decompression of a picture file to 
an original format file which is stored and may be con- 
verted as desired is not known in this field. 
[0079] Similarly, whilst the description refers to the use 
of the main or general processor chip to carry out the 
necessary decompression and conversion steps in 
addition to its other tasks, these steps may also be car- 
ried out by a dedicated processor. 

Claims 

1. A decoder for a digital audiovisual transmission 
system, the decoder comprising a processor 
means for decompressing and displaying com- 
pressed digital picture data and a memory means, 
characterised in that the processor means is 
adapted to decompress and store an image file in 
its substantially original format and subsequently to 
convert the image file to at least a second format for 
storage and display, the f irst and second format ver- 
sions of the image file being stored contemporane- 
ously in the memory means. 

2. A decoder as claimed in claim 1 in which the proc- 
essor means is adapted to convert the image file 
into a plurality of formats stored contemporane- 
ously with the original version in a memory of the 
decoder. 

3. A decoder as claimed in claim 1 or 2 in which the 
processor means is adapted to read and display 
multiple format versions of an image file stored at 
that time. 

4. A decoder as claimed in any preceding claim in 
which the processor means is adapted to define a 
plurality of regions in a graphic layer corresponding 
to a region of the display, each region being defined 
in part by a location coordinate and by the format 
version of the image files that are processed by the 
graphic processor and displayed in this region. 

5. A decoder as claimed in claim 4 in which the proc- 
essor means is adapted to convert an original 
image file destined to be displayed in a region into 
a version corresponding to the format version cur- 
rently used in that region. 

6. A decoder as claimed in claim 4 or 5 in which the 
processor means is adapted to process images in 
the graphic layer superimposed over real-time audi- 
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ovisual digital data and corresponding to one or 
more layers displayed on the screen beneath the 
graphic layer. 

A decoder as claimed in any preceding claim in 
which the processor means is adapted to decom- 
press picture data sent in a compression standard 
that uses a look-up table. 

A decoder as claimed in any preceding claim in 
which the processor means is adapted to decom- 
press picture data sent in a standard that uses a 
red/green/blue colour value associated with each 
pixel. 

A decoder as claimed in any preceding claim in 
which the processor means is further adapted to 
directly decompress picture data regardless its 
compression format into a image file of a predeter- 
mined format. 



10. A decoder as claimed in claim 9 in which the proc- 
essor means may be further adapted to directly 
decompress picture data into a format which uses a 

25 look-up table. 

11. A decoder as claimed in claim 9 or 10 in which the 
processor means may be further adapted to directly 
decompress picture data into a format which uses a 

30 red/green/blue colour value associated with each 
pixel. 

12. A decoder as claimed in any preceding claim in 
which the processor means comprises a general 

35 processor for decompressing digital picture data 
and a graphic processor for preparing the decom- 
pressed data for display. 

13. A method of digital image processing in a decoder 
for a digital audiovisual transmission system, the 
decoder comprising a processor means for decom- 
pressing compressed digital picture data and a 
graphic processor means for preparing the decom- 
pressed data for display, characterised in that the 
general processor decompresses and stores an 
image file in its substantially original format and 
subsequently converts the image file to at least a 
second format for storage and display, the first and 
second format versions of the image file being 
stored contemporaneously in a memory of the 
decoder. 
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